1. Field of the Invention
The present invention relates generally to distributed object-oriented computing systems and, more specifically, to such a system that includes an Enterprise Java Beans(trademark) environment.
2. Description of the Related Art
Object-oriented (OO) computing is perhaps the greatest change that has occurred in the computing paradigm in recent years. The following is a brief synopsis of OO concepts that those readers who are familiar with OO computing may wish to skip. The goal of OO computing is to reduce the time and costs associated with complex software by creating small, reusable sections of program code that can be quickly and easily combined and re-used to create new programs. The code sections are known as objects. OO languages, such as C++ and Java(trademark) have been developed that allow programmers to approach their programming tasks in a way that is believed to be more natural and intuitive than that in which programmers traditionally approached tasks armed only with the tools of procedural (non-OO) programming languages. Using the unique tools or features of an OO language, a programmer can write code to define a software object that models something in the real world. The object can model the attributes or characteristics of the real-world object and, in many cases, also model its behavior.
Objects are instances of classes that define structure and behavior. Objects can be instantiated or created from a class, and then used, stored, and otherwise manipulated in a manner that analogizes them to actual things. The behavior of an object is defined by methods, which are functions or procedures defined in a class and typically can access the internal state of an object of that class to perform some operation. Objects can invoke the methods of other objects.
The unique features of OO computing include, among others, encapsulation and inheritance. Encapsulation is the process of compartmentalizing the elements of an object, such as its contractual interface (with other objects and the outside world) and its implementation. For example, for objects to interact, they need only address each others"" interfaces and do not need to be involved with its internal structure or implementation, which can be hidden or made inaccessible to other objects. Inheritance refers to the ability to define a new class by extending an existing one. Inheritance is a relationship between classes where one class is the parent or superclass class of another. A class can inherit from more than one class; this is known as multiple inheritance.
Java(trademark) is an example of an OO programming language. Although Java(trademark) is not more fully described in this patent specification because it is well-understood by persons skilled in the art to which the invention pertains, the distinction between an interface and an implementation class is one Java(trademark) feature that is important to the understanding of the invention. An interface describes a service or method without providing any implementation of it. The actual implementation or functionality of the method is separately provided by an implementation class. Although a Java(trademark) interface is not a class, like a class an interface has OO properties such as the ability to inherit from another interface. The advantage of separating interface from implementation is that client code can be written using only the interface definition; a client need not know the implementation class. Indeed, the implementation class can be be determined at runtime of the code. This scheme is also known as late binding. It is important to note that the same client code can be run in a given case with a given implementation class and, without change, in another case with another implementation class.
Distributed OO computing refers to a networked system in which a client (computer) can access an object that exists anywhere on the network. CORBA(copyright) or Common Object Request Broker Architecture is an example of a specification promulgated by the Object Management Group (OMG) that facilitates distributed OO computing. A client need not know on which server (computer) the object is stored on the network. It need not know the operating system of that server. It need not know how the object is implemented; the object""s code may be written in essentially any programming language. The client need only know the server interface. A concept that has arisen in the context of distributed OO computing is that of a framework. A framework is a collection of classes that provides an infrastructure within which software developers can work.
Although the foregoing is intended to provide some background information for purposes of this patent specification, OO programming and distributed OO systems are not described in further detail herein because they are well-known to persons skilled in the art to which the below-described invention pertains.
Enterprise Java Beans(trademark) (EJB) is a specification promulgated by Sun Microsystems of Palo Alto, Calif. that describes a server-side services framework in which software developers can create business application programs or, more generally, business objects or components. It is important to note that EJB provides a complete, predefined framework, in contrast to (plain or non-xe2x80x9cEnterprisexe2x80x9d) Java Beans(trademark), which does not. The class that a software developer writes to implement the component functionality is commonly referred to as an Enterprise Java Bean(trademark) (EJB). Two types of EJBs are defined by the specification: session beans, which are stateless, and entity beans, which can provide access to persistent, i.e., stored, data. The emphasis of this framework is on portability. An EJB can be deployed in any computing system that has an EJB environment, without regard to the type of computing platforms in the system. EJB describes a set of application program interfaces (APIs) for accessing services such as naming, persistence and transactions. By conforming their code to these APIs, business software developers can concentrate upon writing code that implements their business functions and not be concerned with services issues. Providing support for complex services is the task of EJB server vendors. Once one has obtained an EJB server, EJB components (i.e., EJBs) can be obtained from any business software vendor and can be expected to run on the EJB server. An important advantage of conforming applications to the EJB specification is that they can use CORBA(copyright) services that are provided by the EJB server.
Component providers must be mindful of whether their customers"" computing systems have an EJB environment or not, potentially requiring the provider to sell two different versions or flavors of the same component. A component that is deployed in an EJB environment (i.e., an EJB) generally has an interface that inherits from an interface known as EJBObject. This means that any client that uses such a component must have access to EJB packages. In some computing systems, not all clients have access to EJB packages. Thus, a component provider could potentially provide an EJB-enabled version of a component accessible to those clients that have such access, and provide a non-EJB version (e.g., implemented in plain or non-xe2x80x9cEnterprisexe2x80x9d Java Beans(trademark)) accessible to those that do not have such access.
It would be desirable to provide a method for providing a service that clients can use independently of whether it is implemented in an EJB or something else, e.g., a plain or non-xe2x80x9cEnterprisexe2x80x9d Java Bean(trademark). The present invention addresses these problems and deficiencies and others in the manner described below.
The present invention relates to a method and object-oriented computing system in which a Java(trademark) implementation of a service is provided dynamically at runtime via a Java(trademark) interface for the service in accordance with the needs of a client computer in one of two varieties: an Enterprise Java Beans(trademark) (EJB) implementation or, alternatively, a non-EJB implementation. Thus, the same service is accessible, without requiring any programming code changes, to both clients operating in an EJB environment and clients operating in a non-EJB environment. The client accesses the service through two non-EJB interfaces, one for the service (object or bean) itself, and the other for an abstract factory class. Both of these client interfaces are non-EJB to avoid dependence upon client access to EJB packages, which may exist for some clients and not for others. These interfaces operate at runtime to provide a non-EJB implementation for the service in the event the client accessing the service is not operating in an EJB environment and, alternatively, to provide an EJB implementation for the service in the event that the client accessing the service is operating in an EJB environment.
The term xe2x80x9cEJB implementationxe2x80x9d refers to a Java(trademark) implementation object that is instantiated by a home interface predefined by the EJB specification. The term xe2x80x9cnon-EJB implementationxe2x80x9d refers to a Java(trademark) implementation object that is not instantiated via the EJB home interface but rather is defined independently of the EJB specification. A non-EJB object may be, for example, a plain (non-xe2x80x9cEnterprisexe2x80x9d) Java(trademark) bean. The service that is ultimately provided and defined by the implementation object may be any suitable service that does not require access to any of the internal features or services provided exclusively by EJB. The service may be, for example, an e-mail server, fax server, print server or a calendaring function, because the software code for such services can be written without reference to any EJB internal services. Other such services will occur readily to those persons skilled in the art to which the invention pertains in view of the teachings of this patent specification. Note that the feature of the Java(trademark) programming language that provides for separation of interface from implementation is an important factor that enables the present invention to operate.
An intermediate layer is provided in the class hierarchy that includes an inner-layer interface class for the service. An outer-layer interface class is also provided. The outer-layer interface class serves as the interface actually used by the client. This inner-layer interface class inherits from both the outer-layer interface class and the EJB object base interface that is predefined in accordance with standard EJB specifications and commonly referred to by the name xe2x80x9cEJBObject.xe2x80x9d
A factory layer having an abstract factory class is provided, which, as selected by late binding of a client computer at runtime, either instantiates an EJB-aware instance of a factory for said service via said home interface class or alternatively instantiates a non-EJB-aware instance of a factory for said service. The decision of which factory instance is used can be based upon any suitable runtime mechanism, such as a system property or whether access to EJB packages is available on the system. Thus, for example, the invention can be used in a distributed system in which certain clients have access to EJB packages and others do not. A client with such access can request an EJB version of the implementation. A client without such access can request a non-EJB version. Regardless of which implementation is requested at runtime, the interface to that implementation remains the same. In other words, both types of clients can use the same interface. The present invention can also be used to facilitate testing of a service object because a software developer can test the object on a local server, i.e., the same server as that on which a non-EJB client program is running, and then commercially deploy the object on servers accessible to EJB clients without changing the interface.